\subsubsection{Autorisation d'acces}

\begin{flushleft}

Il est prévu de restreindre l'acces de l'interface aux seules personnes autorisées(par login et mot de passe) Trois groupes d'utilisateures seront définis : 	\begin{itemize}
		\item Groupe 10 : lecture seule (peut récupérer des fiches d'exercices déjà faites, consulter des exercices… ex : chargés de TD)
		\medskip
		\item Groupe 100 : création de fiches possibles (ex : professeur responsable d'une UE)
		\medskip
		\item Groupe 1000 : administrateur ( peut ajouter directement des exercices , valider les exercices des autres professeurs , ainsi que gérer les paramètres de l'application : fichier entête , organisation des catégories , autorisation d'acces…)
	\end{itemize}
	\medskip
	Ce système de code numérique présente deux avantages majeurs :
	\medskip
	\begin{itemize}
		\item cumulatif : une page autorisée pour le groupe 10 l'est de fait pour tous les utilisateurs dont le groupe est supérieur ou égal à 10
		\medskip
		\item le choix de 10, 100, 1000 (et non par exemple 1 , 2 , 3) laisse une possibilité d'évolutivité , en permettant de créer facilement si besoin des groupes intermédiaires.
	\end{itemize}
\end{flushleft}

\subsubsection{Sauvegarde des données}

\begin{flushleft}
Dans l'optique d'une défaillance du serveur, ou d'une erreur aboutissant à la suppression de fichiers par exemple , il est indispensable d'effectuer des sauvegardes régulières.\\

Trois catégories de sauvegardes sont à distinguer : 
	\begin{itemize}
		\item sauvegarde de l'application (fichiers sources de l'application , schéma de la base de données)
		\medskip
		\item sauvegarde de la base de données(dump)
		\medskip
		\item sauvegarde de fichiers de données(sources TEX principalement)
	\end{itemize}
Ces deux dernières sauvegardes doivent idéalement être stockées sur un autre serveur, dans un autre lieu.
\end{flushleft}

\subsubsection{securite face aux actions malveillantes}

\paragraph{Récupération non autorisée d'un dump de la base de données}
\begin{flushleft}
Un dump représente le schéma de la base de données, ainsi que les requêtes SQL "INSERT" correspondant aux enregistrements. Les sources TEX étant stockées sur le serveur sous forme de fichiers, la seule donnée critique contenue dans la base correspond aux mots de passe des utilisateurs. Mais ceux ci étant stockés en MD5 (hachage non réversible), et du fait que l'on utilise un sel (concaténation du mot de passe avec une chaîne de caractères stockée dans le fichiers de configuration, ce qui donne une chaîne relativement longue, difficilement cassable en bruteforece, c'est à dire en testant tous les cas possibles), il n'y a pas de possibilité de vol d'identifiants. 
\end{flushleft}
\paragraph{Récupération non autorisée d'une sauvegarde (fichiers de données)}
\begin{flushleft}
Étant donnée que toutes les sources TEX sont sauvegardées sous forme de fichiers, ces derniers se retrouvent dans la sauvegarde. En cas de vol du fichier, toutes inforamtions sont divulguées (notamment toutes les solutions de exercices). Il y a donc nécessité à défaut de pouvoir contrôler où il se trouve de crypter ce fichier, ou au moins les parties sensibles, c'est-à-dire la partie "solution" de chaque fiche/exercice. Ce choix sera fait lors de la réalisation, selon les résultats d'un benchmark à réaliser (pour voir quelle solution est la meilleure d'un point de vue de charge CPU). 
\end{flushleft}
\paragraph{Accès non autorisé à la base de données}
\begin{flushleft}
Imaginons quelqu'un qui a réusii à se connecter directement à la base de données. Comme dit précédemment, il n'y a aucune information critique dans cette base. Mais il serait potentiellement possible d'ajouter un nouvel utilisateur "à la main", ou modifier le groupe d'un utilisateur existant. Pour éviter cela, on rajoute un champ "checksum"(calcul en concaténant les données de l'utilisateur avec plusieurs sels) à la table utilisateur, afin de s'assurer de l'intégrité des enregistrements. 
\end{flushleft}
\paragraph{Accès non autorisé aux fichiers de l'application sur le serveur}
\begin{flushleft}
Le problème dans ce cas est que le mot de passe d'accès à la base de données, toutes le clés de cryptage, et la manière de fonctionner détaillée des algorithmes pourront être récupérés. Il faut donc configurer correctement le serveur, ainsi que l'application elle-même pour ne pas laisser de point d'entrée. 
\end{flushleft}
\paragraph{Vol de session}
\begin{flushleft}
En cas de vol d'identifiant de session (vol ou interception de cookie), la session devrait être terminée par le serveur, car il y a une vérification systématique du user-agent, de l'adresse IP, et d'autres informations du client à chaque appel de page. Il n'y a par contre aucune parade si l'utilisateur laisse sa session ouverte sur un ordinateur en accès libre, à part le timeout qui viendra clore la session au bout d'un intervalle de temps déterminé. 
\end{flushleft}